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Abstract 

Program slicing has been mainly studied in the context of imperative languages, where 
it has been applied to a wide variety of software engineering tasks, like program under- 
standing, maintenance, debugging, testing, code reuse, etc. This work introduces the first 
forward slicing technique for declarative multi-paradigm programs which integrate features 
from functional and logic programming. Basically, given a program and a slicing criterion 
(a function call in our setting), the computed forward slice contains those parts of the 
original program which are reachable from the slicing criterion. Our approach to program 
slicing is based on an extension of (online) partial evaluation. Therefore, it provides a 
simple way to develop program slicing tools from existing partial evaluators and helps to 
clarify the relation between both methodologies. A slicing tool for the multi-paradigm lan- 
guage Curry, which demonstrates the usefulness of our approach, has been implemented 
in Curry itself. 

KEYWORDS: forward slicing, partial evaluation, functional logic programming. 



1 Introduction 

Essentially, program slicing is a method for decomposing programs by analyzing 
their data and control flow. It was first proposed as a debugging tool to allow a 
better understanding of the portion of code which revealed an error. Since this 
concept was originally introduced by Weiser l|1979l 11984)1 — in the context of im- 
perative programs — it has been successfully applied to a wide variety of software 
engineering tasks (e.g., program understanding, maintenance, debugging, merging, 
testing, code reuse) . Surprisingly, there are very few approaches to program slicing 
in the context of declarative programming (see Section (SJ. 

Roughly speaking, a program slice consists of those program statements which 
are (potentially) related with the values computed at some program point and/or 



* A preliminary short version of this paper appeared in the Proceedings of the 12th International 
Workshop on Logic Based Program Synthesis and Transformation (LOPSTR 2002). 
This work has been partially supported by the EU (FEDER) and the Spanish MEC under 
grants TIN2004-00231 and TIN2005-09207-C03-02, and by the ICT for EU-India Cross-Cultural 
Dissemination Project ALA/95/23/2003/077-054. 
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(1) read(n) ; 


(1) read(n) ; 


(1) 


(2) i := 1; 


(2) i := 1; 


(2) 


(3) sum := 0; 


(3) 


(3) sum := 0; 


(4) prod := 1; 


(4) prod := 1; 


(4) 


(5) while i <= n do 


(5) while i <= n do 


(5) 


(6) sum := sum + i; 


(6) 


(6) sum := sum + i; 


(7) prod := prod * i; 


(7) prod := prod * i; 


(7) 


(8) i := i + 1; 


(8) i := i + 1; 


(8) 


(9) write (sum) ; 


(9) 


(9) write (sum) ; 


(lO)write(prod) ; 


(lO)write(prod) ; 


(10) 


(a) 


(b) 


(c) 



Fig. 1. Forward and backward slicing — an example 



variable, often given by a pair (line number, variable), referred to as a slic- 
ing criterion. Program slices are usually computed from a program dependence 
graph IjFerrante et al. 19871 IKuck et al. 1 9811 that makes explicit both the data 
and control dependences for each operation in a program. Program dependences 
can be traversed backwards and forwards — from the slicing criterion — giving rise 
to so-called backward and forward slicing, respectively. 

Essentially, a backward slice consists of the parts of the program that (poten- 
tially) affect the values computed at the slicing criterion. In contrast, a forward slice 
consists of the statements which are dependent on the slicing criterion, a statement 
being dependent on the slicing criterion if the values computed at that statement 
depend on the values computed at the slicing criterion or if the values computed 
at the slicing criterion determine if the statement under consideration is executed 
( |Tip 1 995). Consider, e.g., the example ( |Tip 1995| ) depicted in Fig. [I] (a) for com- 
puting the sum and the product of the sequence of numbers 1,2, ... ,n. Fig.^(b) 
shows a backward slice of the program w.r.t. the slicing criterion (10, prod) while 
Fig. ^(c) shows a forward slice w.r.t. the slicing criterion (3, sum). 

Additionally, slices can be dynamic or static, depending on whether a concrete 
program's input is provided or not. Quasi static slicing was the first attempt to de- 
fine a hybrid method ranging between static and dynamic slicing (|Venkate sh 1991). 
It becomes useful when only the value of some parameters is known. This notion is 
closely related to partial evaluation I) Jones et al. 19 935. a well-known technique to 
specialize programs w.r.t. part of their input data. For instance, quasi static slic- 
ing has been applied to program understanding by Harman et al. ( 1995); similarly, 
Blazy and Facon (1998) use partial evaluation for the same purpose. 

All approaches to slicing mentioned so far are syntax preserving, i.e., they are 
mainly obtained from the original program by statement deletion. In contrast, 
amorphous slicing (Ha rman and Danicic 1997(1 exploits different program transfor- 
mations in order to simplify the program while preserving its semantics w.r.t. the 
slicing criterion. From this perspective, partial evaluation could straightforwardly 
be seen as an amorphous slicing technique. More detailed information on program 
slicing can be found in the surveys of Harman and Hierons 120018 and Tip (1995). 

The aim of this work is the definition of a forward slicing technique for a multi- 
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paradigm declarative language which integrates features from functional and logic 
programming, like, e.g., Curry IjHanus 2003|l or Toy ( |L6pez-Fraguas and Sanchez-Hernandez 19 99). 
Similarly to in ( |Reps and Turnidge 1996| ), where a first-order functional language is 
considered, given a program p and a projection function 7r, backward slicing should 
extract a program that behaves like n(p) (e.g., by symbolically pushing n back- 
wards through the body of p). For instance, it can be used to extract a program 
slice for computing the number of lines in a string from a more general program 
that returns a tuple with both the number of lines and the number of characters 
of the string; this is the example that illustrates the backward slicing technique of 
Reps and Turnidge (1996|. Such a slicing technique is considered backward because 
the algorithm proceeds from (part of) the result backwards to the initial function 
call, i.e., in the inverse direction of the standard operational semantics. In contrast, 
here we consider the definition of a forward slicing technique that, given a program 
and a function call, extracts a program containing all the statements which are 
reachable from the slicing criterion. Our slicing technique is considered forward be- 
cause it proceeds from a given function call to its result, i.e., we follow the control 
flow of the standard operational semantics. 

Furthermore, rather than defining a new technique from scratch, we exploit the 
similarities between slicing and partial evaluation (|.Tones et al. 1993j) . Since a par- 
tial evaluator for the considered language already exists, our approach provides a 
simple way to develop a program slicing tool. The main purpose of partial evaluation 
is to specialize a program w.r.t. part of its input data and, hence, it is also known 
as program specialization. The partially evaluated program will be (hopefully) exe- 
cuted more efficiently since those computations that depend only on the known data 
are performed — at partial evaluation time — once and for all. Many (online) partial 
evaluation schemes follow a common pattern: given a program and a function call 
(possibly containing partial data structures by means of free variables) , the partial 
evaluator builds a finite representation — generally a graph — of the possible execu- 
tions of the initial call and, then, systematically extracts a residual program — the 
partially evaluated program — from this graph. 

The essence of our approach can be summarized as follows. First, we consider 
that, in our functional logic context, a function call — possibly containing free vari- 
ables — may also play the role of slicing criterion. Since such a call may have an 
infinite computation space, a primary task of both slicing and partial evaluation 
is the construction of a finite representation of its possible program executions. 
Here, the same algorithm which is used in partial evaluation can be applied for 
computing this finite representation, which will be later used to identify the pro- 
gram statements that are reachable from the slicing criterion. Then, we only need 
to replace the construction of a residual program in partial evaluation by a sim- 
pler post-processing stage that extracts an executable program which includes the 
reachable program statements. 

While partial evaluation usually achieves its effects by compressing paths in the 
graph and by renaming expressions in order to remove unnecessary function sym- 
bols, slicing should preserve the structure of the original program (here, we do 
not consider amorphous slicing): statements can be — totally or partially — deleted 
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but no new statements can be introduced. In order to further clarify the relation 
between partial evaluation and slicing, let us recall the following classification of 
partial evaluators introduced by Gliick and S0rcnsen ( 1996). According to this clas- 
sification, a partial evaluator is 

• Monovariant: if each function of the original program gives rise to (at most) 
one residual function; 

• Polyvariant: if each function of the original program may give rise to one or 
more residual functions; 

• Monogenetic: if each residual function stems from one function of the original 
program; 

• Polygenetic: if each residual function may stem from one or more functions 
of the original program. 

The main contribution of this work is to demonstrate that a forward slicing tech- 
nique for functional logic programs can be obtained by slightly extending a mono- 
variant and monogenetic partial evaluation scheme. Unfortunately, this kind of 
monovariant/monogenetic partial evaluation could be rather imprecise, thus result- 
ing in unnecessarily large residual programs (i.e., slices). In order to overcome this 
drawback, we consider the definition of an extended operational semantics to per- 
form partial evaluations, which helps us to preserve as much information as possible 
while maintaining the monovariant/monogenetic nature of the process. 
The main contributions of this work can be summarized as follows: 

• We define the first forward slicing technique for functional logic programs. Fur- 
thermore, the application of our developments to (first-order) lazy functional 
programs would be straightforward, since either the syntax and the underlying 
(online) partial evaluators — e.g., positive supercompilation ( S0rense n et al. 19961 ) — 
share many similarities. 

• We do not need to consider separately static and dynamic slicing, since the 
underlying partial evaluation scheme naturally accepts partial input data. 

• Our method is defined in terms of an existing partial evaluation scheme and, 
thus, it is easy to implement by adapting current partial evaluators. 

• Finally, our approach helps to clarify the relation between forward slicing and 
(online) partial evaluation. 

This paper is organized as follows. In the next section we recall some foundations 
for understanding the subsequent developments. Section |21 introduces a notion of 
forward slicing in the context of functional logic programming. We then recall, in 
Section^ the narrowing-driven approach to partial evaluation. Sectional defines an 
algorithm for computing program dependences by partial evaluation, while Section^] 
uses these dependences to extract program slices. Section presents a prototype 
implementation of the program slicing tool and show some selected experiments. 
Several related works are discussed in Section |H1 before we conclude in Section 
Proofs of technical results can be found in |Appendix A| 
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2 Foundations 

We recall in this section some basic notions of term rewriting ( Baadc r~and Nipkow 1998| 
|Klop 1992| iTerese 2003(1 and functional lo gic programming <|Hanus 1994(1 . 

2. 1 Preliminaries 

Throughout this paper, we consider a {many-sorted) signature S partitioned into 
a set C of constructors and a set T of (defined) functions or operations. We write 
c/n G C and f/n G T for n-ary constructor and operation symbols, respectively. 
There is at least one sort Bool containing the constructors True and False. The 
set of terms and constructor terms with variables (e.g., x, y, z) from X are denoted 
by T(C U J r , X) and T(C,X), respectively. A term is linear if it does not contain 
multiple occurrences of one variable. The set of variables occurring in a term t is 
denoted by Var(t). A term t is ground if Var(t) = 0. 

A pattern is a term of the form f(d±, . . . , d n ) where f/n € T and di, . . . , d n £ 
T(C,X). A term is operation-rooted (constructor-rooted) if it has an operation 
(constructor) symbol at the root. A position p in a term t is represented by a 
sequence of natural numbers (A denotes the empty sequence, i.e., the root position). 
t\ p denotes the subterm of t at position p, and t[s] p denotes the result of replacing 
the subterm t\ p by the term s. We denote a substitution a by {x\ i— ► ti,...,x n > t n } 
where a{xi) = <, for i = 1, . . . , n (with Xi ^= Xj if i =/= j), and <j{x) = x for all other 
variables x. A substitution a is constructor, if o~(x) is a constructor term for all x. 
The identity substitution is denoted by id. A substitution 9 is more general than ct, 
in symbols 9 < a, iff there exists a substitution 7 such that j o 9 — a ("o" denotes 
the composition operator). Term f' is a (constructor) instance of term f if there is 
a (constructor) substitution ct with t' — o~(t). 

A set of rewrite rules (or oriented equations) I — r such that I $ X, and Var(r) C 
Var(l) is called a term rewriting system (TRS). Terms I and r are called the feft- 
hand side and the right-hand side of the rule, respectively. A TRS 1Z is left-linear 
if / is linear for alH = r G 7?.. A TRS is constructor-based if each left-hand side I is 
a pattern. In the following, a functional logic program is a left-linear constructor- 
based TRS. A rewrite step is an application of a rewrite rule to a term, i.e., t —> p ,r s 
if there exists a position p in t, a rewrite rule R = (I = r) and a substitution cr with 
i|p = <t(Z) and s = t[cr(r)] p . The instantiated left-hand side a(l) of a rule I = r 
is called a redex (reducible expression). Given a relation — >, we denote by its 
transitive and reflexive closure. 

Example 1 

Consider the following TRS that defines the addition on natural numbers repre- 
sented by terms built from Zero and Succ: 1 

Zero + y = y (Rj) 
Succ(x) + y = Succ(x + y) (R 2 ) 

1 In the examples, we write constructor symbols starting with upper case (except for the list 
constructors, "[]" and which are a shorthand for Nil and Cons, respectively). 
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Given the term Succ(Zero) + Succ(Zero), we have the following sequence of rewrite 
steps: 

Succ(Zero) + Succ(Zero) ^a.r 2 Succ(Zero + Succ(Zero) 

—►1,11! Succ(Succ(Zero)) 



2.2 Narrowing 

Functional logic programs mainly differ from purely functional programs in that 
function calls may contain free variables. In order to evaluate terms containing 
free variables, narrowing non-deterministically instantiates these variables so that 
a rewrite step is possible. Formally, t ^(p,ij, CT ) t is a narrowing step if p is a non- 
variable position of t and <r(t) -^ p ,r t'. We often write t t' when the position 
and the rule are clear from the context. We denote by to t n a sequence of n 
narrowing steps to ^cri ■ ■ ■ "~*a„ Ui with <j = o n o • ■ ■ o o\ (if n — then a = id), 
usually restricted to the variables of to. Due to the presence of free variables, a term 
may be reduced to different values after instantiating these variables to different 
terms. Given a narrowing derivation to t n , we say that t n is a computed value 
and a is a computed answer for to. 

Example 2 

Consider again the definition of function "+" in Example ^ Given the term x + 
Succ(Zero), narrowing non-deterministically performs the following derivations: 

x + Succ(Zero) ~»A,R 1 ,{xH.zero} Succ(Zero) 

x + Succ(Zero) "^A,R 2 ,{x M succ( yi )} Succ(yi + Succ(Zero)) 

-^►l.R^yi^Zero} Succ(Succ(Zero)) 

x + Succ(Zero) -^A,R 2 ,{ x ^succ( yi )} Succ(y! + Succ(Zero)) 

> i,R 2 ,{ yi ^succ(y 2 )} Succ(Succ(y 2 + Succ(Zero))) 

> ii,R 1 ,{y 2 ^zero} Succ(Succ(Succ(Zero))) 



-^1 



Therefore, x + Succ(Zero) non-deterministically computes the values 

• Succ(Zero) with answer {x i— > Zero}, 

• Succ(Succ(Zero)) with answer {x i— > Succ(Zero)}, 

• Succ(Succ(Succ(Zero))) with answer {x i— > Succ(Succ(Succ(Zero)))}, etc. 

As in logic programming, narrowing derivations can be represented by a (possibly 
infinite) finitely branching tree. Formally, given a program 1Z and an operation- 
rooted term t, a narrowing tree for t in 1Z is a tree satisfying the following conditions: 
(a) each node of the tree is a term, (b) the root node is t, (c) if s is a node of the 
tree then, for each narrowing step s the node has a child s' and the 

corresponding arc is labeled with (p, R, a), and (d) nodes which are constructor 
terms have no children. 

In order to avoid unnecessary computations and to deal with infinite data struc- 
tures, demand-driven generation of the search space has been advocated by a num- 
ber lazy narrowing strategies (JGiovannetti et al. 1991l|Loogen et al. 1993 Mo reno-Navarro and Rodriguez- Artalejc 
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Due to its optimality properties w.r.t. the length of derivations and the number of 
computed solutions, needed narrowing ( |Antoy et al. 2000| ) is currently the best lazy 
narrowing strategy. 



2.3 Needed Narrowing 

Needed narrowing QAntoy et al. 2000*1 ) is defined on inductively sequential TRSs 
( |Antoy 1992| ), a subclass of left-linear constructor-based TRSs. Essentially, a TRS 
is inductively sequential when all its operations are defined by rewrite rules that, 
recursively, make on their arguments a case distinction analogous to a data type 
(or structural) induction. Inductive sequentiality is not a limiting condition for pro- 
gramming. In fact, the first-order components of many functional (logic) programs 
written in, e.g., Haskell, ML or Curry, are inductively sequential. 

We say that s ^ P: R,cr t is a needed narrowing step iff cr(s) -^> p ,r t is a needed 
rewrite step in the sense of Huet and Levy |1992), i.e., in every computation from 
cr(s) to a normal form, either o~(s)\ p or one of its descendants must be reduced. 
Here, we are interested in a particular needed narrowing strategy, denoted by A 
in QAntoy et al. 20001 Def. 13) which is based on the notion of a deGnitional tree 
( |Antoy 1992| ), a hierarchical structure containing the rules of a function definition, 
which is used to guide the needed narrowing steps. This strategy is basically equiv- 
alent to lazy narrowing ( |Moreno-Navarro and Rodriguez- Artalejo 1992) where nar- 
rowing steps are applied to the outermost function, if possible, and inner functions 
are only narrowed if their evaluation is demanded by a constructor symbol in the 
left-hand side of some rule (i.e., a typical outermost strategy). 

Example 3 

Consider following rules which define the less-or-equal function on natural numbers: 

Zero ^ y = True 

Succ(x) ^ Zero = False 
Succ(x) ^ Succ(y) = x ^ y 

In a term like t\ ^ ti^ it is always necessary to evaluate t± to some head normal 
form (i.e., a variable or a constructor-rooted term) since all three rules defining 
"sj" have a non-variable first argument. On the other hand, the evaluation of t% 
is only needed if t\ is of the form Succ(0. Thus, if t\ is a free variable, needed 
narrowing instantiates it to a constructor, here Zero or Succ (x) . Depending on this 
instantiation, either the first rule is applied or the second argument ti is evaluated. 



2-4 Declarative Multi- Paradigm Languages 

Functional logic languages have recently evolved to so called declarative multi- 
paradigm languages like, e.g., Curry (Hanus 2003), Toy (Hortala-Conzal ez and Ullan 20011 
and Escher ( |Lloyd 1994| ). In order to make things concrete, we consider in this 
work the language Curry, a modern multi-paradigm language which integrates fea- 
tures from logic programming (partial data structures, built-in search), functional 
programming (higher-order functions, demand-driven evaluation) and concurrent 
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■R 


::= Di...D m 


(program) 


t 


::= x 


(variable) 


D 


■■= f(x^) = e 


(rule) 






(constructor call) 


e 


::= t 


(term) 




1 f(tn) 


(function call) 




case x of {p m — 


» e m } (rigid case) 


V 


::= c(x„) 


(flat pattern) 




fcase x of {p m - 


-> e m } (flexible case) 









Fig. 2. Syntax of Flat Programs 



programming (concurrent evaluation of constraints with synchronization on logical 
variables). Curry follows a Haskell-like syntax, i.e., variables and function names 
start with lowercase letters and data constructors start with an uppercase letter. 
The application of function / to an argument e is denoted by juxtaposition, i.e., 
ife). 

The basic operational semantics of Curry is based on a combination of needed 
narrowing and residuation planus 1997(1 . The residuation principle is based on the 
idea of delaying function calls until they are ready for a deterministic evaluation. 
Residuation preserves the deterministic nature of functions and naturally supports 
concurrent computations. The precise mechanism — narrowing or residuation — for 
each function is specified by evaluation annotations. The annotation of a function 
as rigid forces the delayed evaluation by rewriting, while functions annotated as 
flexible can be evaluated in a non-deterministic manner by narrowing. 

In actual implementations, e.g., the PAKCS environment planus et al. 2004|) for 
Curry, programs may also include a number of additional features: calls to external 
(built-in) functions, concurrent constraints, higher-order functions, overlapping left- 
hand sides, guarded expressions, etc. In order to ease the compilation of programs 
as well as to provide a common interface for connecting different tools working on 
source programs, a Bat representation for programs has recently been introduced. 
This representation is based on the formulation of Hanus and Prehofer (1999) to 
express pattern-matching by case expressions. The complete flat representation is 
called FlatCurry planus et al. 20 04) and is used as an intermediate language during 
the compilation of source programs. 

In order to simplify the presentation, we will only consider the core of the flat 
representation. Extending the developments in this work to the remaining features 
is not difficult and, indeed, the implementation reported in Section covers many 
of these features. The syntax of flat programs is summarized in Fig. where 
stands for the sequence of objects oi, . . . , o n . We consider the following domains: 

x,y,z G X (variables) a,b,c G C (constructor symbols) 

f,g,h G T (defined functions) ei,e2,... G £ (expressions) 
t\,ta,... G T (terms) vi,V2,... G V (values) 

The only difference between terms and expressions is that the latter may con- 
tain case expressions. Vaiues are terms in head normal form, i.e., variables or 
constructor-rooted terms. A program 1Z consists of a sequence of function defi- 
nitions; each function is defined by a single rule whose left-hand side contains only 
different variables as parameters. The right-hand side is an expression e composed 
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by variables, constructors, function calls, and case expressions for pattern-matching. 
The general form of a case expression is: 2 

(f)case x of {c x (x^) -> er, ■ ■ Cm (*^n m ) ^ e rn } 

where a; is a variable, c±, . . ., c m are different constructors of the type of x, and 
ei, . . . , e m are expressions (possibly containing nested (f)case , s). The variables 
are local variables which occur only in the corresponding subexpression ei . The dif- 
ference between case and fcase only shows up when the argument, x, is a free vari- 
able (within a particular computation): case suspends — which corresponds to resid- 
uation, i.e., pure functional reduction — whereas fcase nondeterministically binds 
this variable to a pattern in a branch of the case expression — which corresponds 
to either narrowing ( |Antoy et al. 2000| ) and driving IjTurchin 1986|l . Note that our 
functional logic language mainly differs from typical (lazy) functional languages in 
the presence of flexible case expressions. 

Example 4 

Consider again the rules defining functions "+" (Example^) and (Example |3J). 
These functions can be defined in the flat representation as follows: 3 

x + y = fcase x of { Zero — > y; 

Succ n — > Succ (n + y) } 

x ^ y = fcase x of { Zero — > True; 

Succ n — > fcase y of { Zero — * False; 

Succ m — > n $5 m } } 

An automatic transformation from source (inductively sequential) programs to flat 
programs has been introduced by Hanus and Prehofer ( 1999). Translated programs 
always fulfill the following restrictions: case expressions in the right-hand sides 
of program rules appear always in the outermost positions (i.e., there is no case 
expression inside a function or constructor call) and all case arguments are variables, 
thus the syntax of Fig. [21 is general enough for our purposes. We shall assume these 
restrictions on flat programs in the following. 

The operational semantics of flat programs is shown in Fig. It is based on the 
LNT — for Lazy Narrowing with definitional Trees — calculus of Hanus and Prehofer 
(1999). The one-step transition relation => ff is labeled with the substitution a 
computed in the step. Let us briefly describe the LNT rules: 

The select rule selects the appropriate branch of a case expression and continues 
with the evaluation of this branch. This rule implements pattern matching. 

The guess rule applies when the argument of a flexible case expression is a vari- 
able. Then, this rule non-deterministically binds this variable to a pattern in a 
branch of the case expression. The step is labeled with the computed binding. 



2 We write (f)case for either fcase or case. 

3 Although we consider in this work a first-order representation — the flat language — we use a 
curried notation in concrete examples (as in Curry). 
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(select) (f)case c(t n ) of {p m — > e m } =>- id a(e 8 ) 

if pi = c(a£), c e C, and a = {x n ^ £„} 

(guess) fcase x of {p m — > e m } => CT tr(ej) 

if <t = {x and « 6 {1, . . . , m} 

(case eval) (J) case e of {p m — ► e m } =^ CT a ((f) case e' 0/ {p m -> e m }) 

if e is not in head normal form and e => CT e' 

(fun) /(Q =>id o-(e) 



if /(avi) = e eTZ and a = {x„ £„} 



Fig. 3. Standard Operational Semantics (LNT calculus) 

Observe that there is no rule to evaluate a rigid case expression with a variable 
argument. This situation produces a suspension of the evaluation. 

The case eval rule can be applied when the argument of the case construct is not 
in head normal form (i.e., it is either a function call or another case construct). 
Then, it tries to evaluate this expression recursively. 

Finally, the fun rule performs the unfolding of a function call. As in proof pro- 
cedures for logic programming, we assume that we take a program rule with fresh 
variables in each such evaluation step. 

Note that there is no rule to evaluate terms in head normal form; in this case, 
the computation stops successfully. An LNT derivation is denoted by eo e rn 
which is a shorthand for the sequence eo =>a-i ■ ■ ■ = ^"<r n e n with a = a n o • • • o a\ 
(if n = then a = id). An LNT derivation e =^* a e' is successful when e' is in 
head normal form. Then, we say that e evaluates to e' with computed answer a. 

Example 5 

Consider the function of Example 0] Given the initial call "(Succ x) ^ y", 
the LNT calculus computes, among others, the following successful derivation: 

(Succ x) ^ y 

==r-jd fcase (Succ x) of (f un ) 
{Z — > True; 

(Succ n) — > fcase y of {Z — > False; (Succ m) — > n ^ m}} 
=r-j(j fcase y of {Z — > False; (Succ m) — > x ^ m} (select) 
=^{y^z} False (guess) 
Therefore, (Succ x) ^ y evaluates to False with computed answer {y 1— > Z}. 



3 Forward Slicing 

In this section, we formalize our notion of forward slice in the context of functional 
logic programs. As mentioned before, in our setting any function call may play the 
role of slicing criterion. Essentially, given a program 1Z and a (partially instanti- 
ated) call t — the slicing criterion — an associated forward slice is a fragment of 1Z 
which contains all the statements which are necessary for executing the call t, i.e., 
which are needed to evaluate the slicing criterion. This relation between needed- 
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ness — in the sense of Huet and Levy l|1992(l — and slicing is not new; indeed, there 
exist several approaches to slicing of functional programs which rely on the com- 
putation of neededness information (Biswas 1997; |FTeld and Tip 1998| ). Clearly, t 
must compute the same value in TZ and in the computed slice. In particular, the 
original program is always a correct slice w.r.t. any slicing criterion. Our aim is 
thus to find smaller slices. 4 Furthermore, we do not distinguish between dynamic 
and static slicing, since it only depends on the degree of instantiation of the slicing 
criterion; in order words, we consider a sort of quasi static slicing l|Venkatesh 19911. 

As mentioned before, we do not consider the construction of amorphous slices; 
otherwise, partial evaluation could straightforwardly be seen as a slicing technique. 
Here, we only allow the deletion of some elements of the original program: 

Term deletion: This is the simplest kind of deletion. It consists of the removal of 
subterms which are not needed to perform computations with the slicing criterion. 

Branch deletion: By using the partially known data in the slicing criterion, some 
case branches become useless and can be deleted. 

Function deletion: Finally, those functions which are not necessary to evaluate the 
slicing criterion can be completely deleted from the slice. 

Analogously to Schoening and Ducasse (fl996 ) , our notion of program slice is formal- 
ized in terms of an abstraction relation. In the following, we consider that program 
signatures are implicitly augmented with the 0-ary constructor T, a special symbol 
which is used to denote that some code fragment is missing. 

Definition 1 [term abstraction) 

A term t' is an abstraction of term t, in symbols t' >z t, iff t' = T or t' = t. 
Definition 2 [expression abstraction) 

An expression e' is an abstraction of an expression e, in symbols e' y e, iff one of 
the following conditions holds: 

• e' = T (i.e., a case structure is completely deleted); 

• e' = e; 

• e' = (f)case x of {p' n — > e' n }, e — (f)case x of {p n — * e„}, and e[ y a for all 
i = 1, . . . , n. 

Definition 3 [program slice) 

A program TZ 1 = [D[ 7 . . . , D' m ) is a slice of a program TZ = (Di, . . . , D m ), in symbols 
TZ' h TZ, iff for alii = 1, . . . , m, D[ = [f[x^) = e'), D l = (f(x^) = e), and e' h e. 

Roughly speaking, a program TZ 1 is a slice of program TZ if it can be obtained by 
replacing some subterms, case branches, and right-hand sides of function definitions 
by T. Trivially, program slices are steadily executable (and fulfill the syntax of 
Fig. [2J by just considering T as an arbitrary constant of the program's signature. 
The interest in producing executable slices comes from the fact that it facilitates 



4 Weiser proved that computing the minimal slice is generally undecidablc iWciscr 19841. 
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main op xs = f case op of { Len —* f st (lenmax xs) ; 

Max — > snd (lenmax xs) } 
lenmax xs = (len xs, max xs) 
len xs = fcase xs of { [] — > Zero; 

(x:xs) —> Succ (len xs) } 
max xs = fcase xs of { (y:ys) — > fcase ys of 

{ □ - y; 

(z:zs) -> if (y ^ z) then max (z:zs) 

else max (y:zs) } } 

x ^ y = fcase x of { Zero — ► True; 

Succ n — > fcase y of { Zero — > False; 

Succ m — *• n ^ m } } 

fst x = fcase x of { (a,b) — > a } 
snd x = fcase x of { (a,b) — > b } 

Fig. 4. Example lenmax 

program reuse and, more importantly, it allows us to apply a number of existing 
techniques to the computed slice (e.g., debugging, program analysis, verification, 
program transformation) . 

So far, we have only considered the shape of a slice. Now, we consider the se- 
mantics of the slicing process: 

Definition 4 (correct slice) 

Let TZ be a program and t a term. We say that TZ' is a correct slice of TZ w.r.t. t iff 

• TZ' is a program slice of TZ (i.e., TZ' hTZ), and 

• t =>v h in TZ iff t =>J 2 fa in TZ' , where t\, fa are values (different from T), 
fa t tii and o i = (72 (modulo variable renaming). 

Observe that evaluations in the slice may produce values with some occurrences of 
T at inner positions, which is safe in our context since only the outermost symbol 
is observable in the LNT semantics. On the other hand, no abstraction is needed 
for substitutions, since the computed bindings can only map variables to patterns 
of the form c(x^) with no occurrences of T (see rule guess in Fig. 

Example 6 

Consider the program excerpt shown in Fig. 0] for computing the length or the 
maximum of a list, depending on the value of the first parameter of main. Standard 
functions "len", "max", "fst", and "snd" return the length of a list, the maximum 
of a list, the first element of a tuple, and the second clement of a tuple, respectively. 
Given the slicing criterion "main Len xs" , the following slice can be obtained: 

main op xs = fcase op of { Len — > fst (lenmax xs) ; 

Max -> T } 

lenmax xs = (len xs, T) 

len xs = fcase xs of { [] — > Zero; 

(x:xs) — > Succ (len xs) } 

max xs = T 
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x < y = T 

fst x = fcase x of { (a,b) — > a } 
snd x = T 

Here, we have performed three different kinds of code deletion: 

Term deletion: The evaluation of the call to function "max" in the right-hand side 
of "lenmax" is not needed — since function "fst" only demands the evaluation of 
the first component of the tuple — and, thus, it has been replaced by T. 

Branch deletion: In the definition of function "main" , the second branch of the case 
expression is not needed to execute the slicing criterion; therefore, it has also 
been replaced by T. 

Function deletion: Since functions "max", and "snd" are no longer necessary 

to evaluate the slicing criterion, their definitions have been replaced by T. 

Note that this slice could not be constructed by using a simple graph of functional 
dependencies (e.g., functions "snd", "lenmax", and "^5" depend on function "main" 
but they do not appear in the computed slice). 

In order to simplify the representation of program slices, in the following we adopt 
the following conventions: 

• case branches of the form p — > T are deleted and 

• function definitions of the form f(x^) = T are removed from the slice. 

Therefore, the slice of Example is simply written as follows: 

main op xs = fcase op of { Len — * fst (lenmax xs) } 

lenmax xs = (len xs, T) 

len xs = fcase xs of { [] — » Zero; 

(x:xs) — > Succ (len xs) } 
fst x = fcase x of { (a,b) — ► a } 

4 Monovariant/Monogenetic Partial Evaluation 

As discussed in the introduction, our developments rely on the fact that forward 
slicing can be regarded as a form of monovariant/monogenetic partial evaluation. 
This requirement is necessary in order to ensure that there is a one-to-one relation 
between the functions of the original and residual programs, which is crucial to 
produce a fragment of the original program rather than a specialized version. 

In this section, we first recall the basic narrowing-driven partial evaluation (NPE) 
scheme l|Albert and Vidal 2002j) and, then, modify it in order to obtain a mono- 
variant and monogenetic partial evaluator. 

Essentially, NPE proceeds by iteratively unfolding a set of function calls, testing 
the closedness of the unfolded expressions, and adding to the current set those 
calls (in the derived expressions) which are not closed. This process is repeated 
until all the unfolded expressions are closed, which guarantees the correctness of 
the transformation process ( |Alpuente et al. 1998| ), i.e., that the resulting set of 
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Input: a program 1Z and a term t 
Output: a residual program H' 
Initialization: i := 0; Eq := {t} 
Repeat 

E' := unfold(E t ,TZ); 

E l+1 :— abstract(Ei, E'); 

i := i + 1; 
Until E % = Ei-i (modulo renaming) 
Return: 

1Z' := build _residual_program(Et, TV) 



Fig. 5. Narrowing-Driven Partial Evaluation Procedure 

expressions covers all the possible computations for the initial call. This iterative 
style of performing partial evaluation was first described by Gallagher l|1993[l for 
the partial evaluation of logic programs. 

The computation of a closed set of expressions can be regarded as the construction 
of a graph containing the program points which are reachable from the initial call. 
Intuitively an expression is closed whenever its maximal operation-rooted subterms 
(function calls) arc instances of the already partially evaluated terms. Formally, the 
closedncss condition is defined as follows: 

Definition 5 (closedness) 

Let £ be a finite set of expressions. We say that an expression e is closed w.r.t. E 
(or i?-closed) iff one of the following conditions hold: 

• e is a variable; 

• e = c(ei, . . . , e„) is a constructor call and e%, . . . , e„ are recursively -Enclosed; 

• e = (f)case e' of {p m — > e m } is a case expression and e', ei, . . . , e m are 
recursively i?-closed; 

• e is operation- rooted, there is an expression e' 6 E, a matching substitution 
a with e = er(e'), and, for all x i— > e" G er, e" is recursively i?-closed. 

The basic partial evaluation procedure is shown in Fig. |SJ Let us explain the oper- 
ators in this procedure: 

• The operator unfold takes a program and a set of expressions Ei — {ei , . . . , e„}, 
computes a finite set of (possibly incomplete) finite derivations ej =>* ej, 
j = 1, . . . , n, and returns the set of derived expressions E' — {e[, . . . , e' n }. 
Here, partial computations are performed with the LNT calculus of Fig. |3| 
slightly extended to avoid the backpropagation of bindings: the RLNT (for 
Residualizing LNT) calculus of Albert et al. (2O03|). The main difference be- 
tween the LNT and the RLNT calculi is that the non-deterministic rule guess 
of the LNT calculus is replaced by a deterministic rule that leaves the case 
structure untouched and proceeds with the evaluation of the branches. 

• Function abstract is then used to properly add the new expressions to the 
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current set of (to be) partially evaluated expressions. For instance, a trivial 
abstraction operator could be defined as follows: 

abstract (Ei, E') = Ei U {e G E' | there is no e' G Ei such that e = e'} 

Here, only the new expressions that are not equal (modulo variable renaming) 
to some expression in the current set Ei are added. This abstraction operator, 
however, does not guarantee the termination of the process since an infinite 
number of different expressions can be derived. In general, a termination 
test is also applied, e.g., Alpuente et al. ((3998) consider a variant of the 
Kruskal tree condition called "homeomorphic embedding" <|Leuschel 2 002): 
if an expression embeds another expression in the current set, some form of 
generalization — usually the most specific generalization operator — is applied 
and the generalized term is added to the current set. 
• The main loop of the algorithm can be seen as a pre-processing stage whose 
aim is to find a closed set of expressions. Note that no residual rules are 
actually constructed during this phase. Only when a closed set of expressions 
is eventually found, residual rules are built as follows: 

build jresidual jprogram{Ei ,1Z) = {e = e \ e G Ei and e =>* e' in 1Z} 

In general, this operator also applies a renaming of expressions and some 
post-unfolding transformations which are not relevant for this work; we refer 
the interested reader to ({Albert and Vidal~20 02). 

In principle, the NPE scheme has been designed to achieve both polyvariant and 
polygenetic specializations. In this work, however, we are interested in the definition 
of a less powerful monovariant and monogenctic scheme. For this purpose, we should 
impose several restrictions to the procedure of Fig. |SJ 

1. Firstly, the current set Ei should only contain operation-rooted terms with- 
out nested function calls (i.e., of the form f(t n ), where / is a defined function 
symbol and t\, . . . , t n are constructor terms) . This is necessary to ensure that 
partial evaluation is monogenetic and, thus, we do not produce residual func- 
tions that mix several functions of the original program. 

2. Secondly, the unfolding operator should perform only a one-step evaluation 
of each call rather than a computation of an arbitrary length. This condi- 
tion is required to guarantee that no reachable function is hidden by the 
unfolding process. For instance, if we would allow a computation of the form 
f x =>• g x =>■ h x, the unfolding operator would only return h x, while 
g x should also be part of the slice. 

3. Finally, the abstraction operator should ensure that the current set of terms 
contains at most one term for each function symbol. In this way, we enforce 
the monovariant nature of the partial evaluation process, i.e., that only one 
residual definition is produced (at most) for each original function. 

Unfortunately, such a monovariant /monogenetic partial evaluator would propagate 
information poorly. In order to overcome this drawback, in the next section we 
introduce a carefully designed operational mechanism which avoids the loss of in- 
formation (i.e., program dependences) as much as possible. 
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5 Computing Program Dependences 

In this section, we introduce the kernel of a monovariant and monogenetic partial 
evaluator that can be used to compute program dependences. In principle, such a 
partial evaluator could proceed as follows: 

• terms containing nested function symbols are Rattened; 

• terms in the current set of (to be) partially evaluated terms which are rooted 
by the same function symbol are generalized with some appropriate general- 
ization operator (e.g., the most specific generalization operator). 

However, flattening terms with nested function symbols would imply a serious loss 
of precision. For instance, a term of the form "f st (lenmax xs)" would be replaced 
by the terms "fst y" and "lenmax xs", where y is a fresh variable, thus missing 
the fact that fst is called with the result of "lenmax xs". 

In order to avoid this loss of precision, we drop the first restriction above, i.e., 
we consider arbitrary operation-rooted terms during partial evaluation. However, 
we should still ensure that only a one-step of unfolding is applied to each term in 
order to guarantee that no reachable function is hidden by the unfolding process. 
In our flat language, function calls are evaluated lazily: a term containing nested 
function calls is evaluated by first unfolding the outermost function; inner function 
calls are only evaluated on demand, i.e., when they appear as the argument of some 
case expression. For instance, "fst (lenmax xs)" is unfolded to 

fcase (lenmax xs) of { (a,b) — > a } 

Then, the evaluation of function "fst" cannot continue until the inner call to 
"lenmax" is reduced to a value. Unfortunately, this interleaved evaluation is prob- 
lematic in our context since it would give rise to a polygenetic partial evaluation 
(i.e., a residual function comprising the evaluation of both fst and lenmax) . In 
contrast, we should perform a complete one-step unfolding of each function call sep- 
arately, i.e., a function unfolding followed by the reduction of all the case structures 
in the unfolded expression. 

For this purpose, we extend the partial evaluation mechanism in order to work 
on states rather than on expressions. 

Definition 6 [state) 

A state is a pair of the form (e, S), where e is an expression (to be evaluated) and 
S is a stack (a list) which represents the current "evaluation context" . 5 The empty 
stack is denoted by [ ] . 

For example, the previous expression "fst (lenmax xs)" could now be flattened 
as follows (see Example EJ: (lenmax xs, [(fst x, x)]), which means that lenmax xs 
is ready to perform a complete one-step unfolding; when this evaluation is per- 
formed, the initial term can be reconstructed thanks to the information in the 
stack, (fst x, x), which means that the initial term has the form fst x, where x is 



° Similar operational semantics with a stack can be found in HAlbert et aT~20 05 ScstofQMZj ■ 



Forward Slicing by Partial Evaluation 



17 



the result of evaluating the first component of the state (i.e., the result of evaluating 
lenmax xs). Thanks to the use of states, we do not miss the fact that f st is called 
with the result of "lenmax xs" . 

Figure [5] shows an extended operational semantics which is appropriate to deal 
with states. Let us briefly explain the rules of this operational semantics. 

Rules select and guess proceed in a similar way as their counterpart in the stan- 
dard semantics of Fig. 

Rule flatten is used to avoid the unfolding of those (operation-rooted) terms 
whose unfolding would demand the evaluation of some inner call. This is necessary 
to ensure that partial evaluation is monogenctic. In this case, we delay the function 
unfolding and continue with the evaluation of the demanded inner call. Auxiliary 
function Hat is used to flatten these states. Here, we use subscripts in the arrows to 
indicate the application of some concrete rule(s). Function Hat proceeds as follows: 

When the expression in the input state can be reduced by using rules select and 
guess to a case expression with a function call in the argument position (which 
is thus demanded), function Hat returns a new state whose first component 
is the demanded call, g(t' m ), and whose stack is augmented by adding a new 
pair (J(t n )\g{t' m )/x\,x). Here, f(t n )[g(t' n )/x] denotes the term obtained from 
f(tn) by replacing the selected occurrence of the inner call, g(t' n ), with a fresh 
variable x. This pair contains all the necessary information to reconstruct the 
original expression once the inner call is evaluated to a value (in rule replace). 

Example 7 

Consider again the program of Example El In order to flatten the following expres- 
sion: (fst (lenmax xs), []), we proceed as follows. First, we perform a function 
unfolding so that we get: 

(fcase (lenmax xs) of {(a,b) — > a}, []} 

Now, we try to evaluate this state by means of rules select and guess. Since no 
reduction is possible and the case structure has a function call in the argument 
position, function flat returns the state 

(lenmax xs, [(fst x, x)]) 

where x is a fresh variable. Observe that this state cannot be further flattened since 
a function unfolding returns the state 

((len xs,T), []} 

which cannot be reduced by rules select and guess and which contains no function 
call in the argument position of a case expression. Therefore, in this case, function 
flat returns _L and no step with rule flatten can be done. 

Rule fun performs a simple function unfolding when rule flatten does not apply, i.e., 
when function Hat returns _L. 

Finally, rule replace allows us to retake the evaluation of some delayed function 
call once the demanded inner call is reduced to a value. 
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(select) ( {f)case c(t„) of {p k -> e k }, S) (p(e»), S) 

if pi = c(5vT), c G C, and p = {a; n h- > i„} 
(guess) ( (f)case x of {p k => e^}, S 1 ) => (p(e B ), 5) 

if p = {k p;} and i 6 {1, . . . , k} 
(flatten) (f(Q, _ 5) (,?(<£), S' > 

iiflat(f(u:),S) = (g(t£),Sf) 
(fun) (/(£), _ 5) =» (p (e), 5> 

if flat(f(t„), S) = _L, f(x^) = e £lZ, and p = {a;„ -> t„} 
(replace) ( w, (/(£), i) : 5 ) => <p(/(£)), S) 

if u is a value and p = {iHt} 

where flat({f(Q, S)) = if (p(e), []) ^^ ct/gues ^((/)™ se 9® «/ {•••}, []) 

then (ff(0,(/(«n)[sr(0/a:]>a:) : S) 
else _L 



with /(x„) = e e1Z, and p = — > t n } 



Fig. 6. Extended Operational Semantics 



The extended operational semantics behaves almost identically to the standard 
semantics of Fig. |3 There are, though, the following main differences: 

• Now, the one-step relation =>■ is not labeled with the computed bindings 
since we are not interested in computing answers but only in obtaining the 
functions which are reachable from the initial call. 

• In the standard semantics, rigid case expressions with a free variable in the 
argument position suspend. In our case, rule guess proceeds with their evalu- 
ation as if they were flexible. This is motivated by the fact that we may have 
incomplete information; hence, in order to be on the safe side — and do not 
miss any reachable function — we should explore all the alternatives of rigid 
case expressions. 

• The order of evaluation is slightly changed. In our extended semantics, we 
delay those function unfoldings which cannot be followed by the reduction of 
all the case expressions in the corresponding right-hand side. 

In spite of these differences, both calculi trivially produce the same results for input 
expressions involving no suspension. Roughly speaking, the extended semantics is 
in between the standard operational semantics and its residualizing version used to 
perform partial computations in the NPE framework ll Albert et al. 2003). 

Example 8 

Consider again the program of Example^! Given the initial term f st (lenmax xs) , 
we have (among others) the following (incomplete) computation with the standard 
semantics of Fig. |3 

fst (lenmax xs) =>id fcase (lenmax xs) of {(a,b) —* a} (f un ) 
=>id fcase (len xs, max xs) of {(a,b) — » a} (fun) 
=>id len xs (select) 
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Input: a program 1Z and an operation-rooted term t 
Output: a set of states S 

Initialization: i := 0; So := {(*', S)}, where (t, [ ]) =>f* atten {f , S) ^flatten 
Repeat 

S' := unfold (Si, TV); 

Si+i :— abstract(Si,S'); 

i := i + 1; 
Until Si = <Si_i (modulo renaming) 
Return: S := <S; 



Fig. 7. Computation of Reachable Program Points 

On the other hand, the extended operational semantics of Fig. performs the 
following equivalent derivation: 

(fst (lenmax xs), []) =>■ (lenmax xs, [(fst x,x)]) (flatten) 

=> ((len xs , max xs),[(fst x,x)]) (f un ) 

=> (fst (len xs, max xs),[]) (replace) 

(fcase (len xs, max xs) of {(a,b) — >-a}, []) (fun) 

=>■ (len xs, []) (select) 

The relevance of the extended semantics stems from the fact that computations can 
now be split into a number of consecutive sequences of steps of the form: 

''flatten '"fun '"select/guess '"replace ' flatten -'fun '"select/guess '"replace ' ' ' 

^ / ^ * 

\/ ^ 

seg_l seqJ2 

where each subsequence, seq_i, represents a complete one-step unfolding of some 
function call. From these sequences, a monogenetic/monovariant partial evaluation 
scheme can easily be defined and, thus, the algorithm for computing dependences 
in our program slicing technique. 

The algorithm of Fig. [S] is now slightly modified in order to work with states. 
The new algorithm (depicted in Fig. |7J) does not compute a residual program but 
only the set of states which are reachable from the initial call. In other words, it 
returns the counterpart of the final set of closed terms computed by the algorithm 
of Fig. [SJ The new algorithm starts by flattening the initial term in order to ensure 
that a complete one-step unfolding can be performed. We now tackle the definition 
of appropriate unfolding and abstraction operators. First, the one-step unfolding 
operator is defined as follows: 

Definition 7 (unfold) 

Let S be a set of states. The unfolding operator unfold is defined by 

unfold(S) = (J unf(s) 
ses 

where 

Unf((t,S)) = {(t',S) | (i,S> ^ fun (t",S) ^: elect/guess (f,S) ^se.ect/gness} 

This unfolding operator always performs a complete one-step unfolding of each 
input expression. The associated stack S remains unchanged since only rules flatten 
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and replace can modify the current stack. Function unf returns a set of derived 
states because of the non-determinism of the underlying operational semantics. 

Example 9 

Consider again the program of Example [BJ We illustrate function unf by means of 
some simple examples: 

im/((lenmax xs, [(fst x,x)]}) = ((len xs , max xs), [(fst x,x)]) 

unf ((f st (len xs, max xs), [])) = (len xs, []) 

according to the partial computation in Example |H1 

Before defining our abstraction operator, we need the following auxiliary notion: 
Definition 8 {flattened state) 

Let s be a state returned by the operator unfold with s =>* ep | ace/ /f| atten s' 7^*. Then 
s' is called a flattened state. 

Flattened states have a particular form, as stated by the following result: 
Lemma 1 

Let s be a flattened state. Then s has the form (v, [ ]), where v is a value, or 
(/(<„), 5), where f(t n ) is an operation-rooted term. 

In order to add new states to the current set of states, we introduce the following 
abstraction operator: 

Definition 9 [abstract) 

Let S and S' — {si, . . . , s n } be sets of states. Our abstraction operator proceeds as 
follows: abstract{S,S') = abs(abs(. . . abs(S, s{) . . . , s' n ), where: 



Basically, function abstract starts by flattening the input states by applying (zero 
or one step of) rule replace, followed by (zero or more steps of) rule flatten. 

Definition 10 (abs) 

Function abs is defined inductively on the structure of flattened states (according 
to Lemma H): 



abs(S,(x,[]))=S 

abs(S, (c(t n ),[])) = abstract (S,S') 

if t' m are the maximal operation-rooted subterms of c(t n ) and S' = {(t' m , [])} 

abs(S,(f(Q ) S))= _ 

' S U {(f(t n ), S)} if there is no state (f(t^), S') in S 

S else if (f(t n ), S) is 5-closed 

< abstract{S*, S") otherwise, where (/©,£") G S, 




msg({f(t< n ),S'),(f(tn),S)) = ({f(W,S'),S") 
and S* = (S\ {</(£), S')}) U {(/(C), S')} 
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Informally speaking, function abs determines the corresponding action depending 
on the first component of the new state. If it is a variable, we discard the state. If 
it is constructor-rooted, we try to (recursively) add the maximal operation-rooted 
subterms. If it is a function call, then we have three possibilities: 

• If there is no call to the same function in the current set, the new state is 
added to the current set of states. 

• If there is a call to the same function in the current set, but the new call is 
closed w.r.t. this set, it is discarded. 

• Otherwise, we generalize the new state and the existing state with the same 
outermost function — which is trivially unique by definition of abstract — and, 
then, we try to (recursively) add the states computed by function 771517. 

The notion of closedness is easily extended from expressions to states: a state (£, S) 
is closed w.r.t. a set of states S iff S[t] is T-closed (according to Def. EJ, with 
T = {S'[t'} I (t',S') £ S}. Here, S[t] denotes the term represented by (t,S), i.e., 
inner calls are moved back to their positions in the outer calls of the stack. For 
instance, given the state 

(£, S) = (y, [(len x 2 , x 2 ), (f st (x 1; snd z), xj.)]) 

we have S[t] — f st (len y, snd z). 

The operator msg on states is defined as follows. First, we recall the standard 
notion of msg on terms: a term £ is a generalization of terms t\ and £2 if both 
t\ and £2 are instances of £; furthermore, term £ is the msg of £1 and £2 if £ is a 
generalization of £1 and £2 and, for any other generalization £' of £1 and £2, £ is an 
instance of £'. Now, the msg of two states is defined by 

msg({ti, Si), (£2, ^2)) = ((£, Si), calls (ai) U calls ((T2) U calls (S2)) 

where msg(ti, £2) = t, and ci and a 2 are the matching substitutions, i.e., <Ti(£) = £1 
and <72(£) = £2- The auxiliary function calls returns a set of states of the form (£, []) 
for each maximal operation-rooted term £ in (the range of) a substitution or in a 
stack. 

Example 10 

Consider the set of states S = {(len xs, []}, (f st (a,b), [])}. We illustrate function 
(abs) by means of some simple examples: 

abs(S, (max xs, [ ])) = S U {(max xs, [ ])} 
since there is no state rooted by function max in S, 

abs (S, (len (y :ys), [])) = S 
since (len (y:ys), []) is 5-closed (i.e., len (y:ys) is an instance of len xs), and 

abs(S, (fst z, []}) = {(len xs, []}, (fst w, [])} 
since there is a state (fst (a,b), []} rooted by function fst, the state (fst z, []) 
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is not 5-closed (since fst z is not an instance of fst (a,b), the most specific 
generalization of the states (fst (a,b)) and (fst z, []} returns (fst w, []}, and 

abs({{len xs,[])},(fst w, [])) = {(len xs,[]), (fst w, [])} 

since there is no state in {(len xs, []}} rooted by function fst. 

Our operator abstract can be seen as an instance of the parametric abstraction 
operator introduced by Alpuente et al. I|1998f) particularized to consider states 
(rather than terms) and monovariant partial evaluation (thus, only one operation- 
rooted term is allowed for each defined function symbol). Our abstraction operator 
is safe in the following sense: 

Lemma 2 

Let S be a set of flattened states and S' a set of unfolded states (as returned by 
unfold). Then the states in S U S' are closed w.r.t. abstract(S,S'). 

This lemma is a crucial result to ensure the correctness of our approach. In fact, 
it will allow us to prove that the generated program is a correct slice according to 
Definition 0] 

Example 11 

Consider again the program of Example[fJ] Given the slicing criterion "main Len xs" , 
the initial set of states is So = {(main Len xs, [])}. Now, we show the sequence of 
iterations performed by the algorithm of Fig. 

<Sq = {(fst (lenmax xs), [])} 

<Si = So U {(lenmax xs, [(fst x,x)])} 

S[ =iSgU{((len xs,max xs), [(fst x, x)])} 

1S2 = Si U {(f st (lenxs, max xs), [ ])} 

<% = <S(u{(len xs,[]}} 

S3 =5 2 U{(len xs, []}} 

S' 3 = S' 2 U {(Zero, []), (Succ (len xs),[]}} 

Sa = S3 

where S^ — unfold(Si,lZ) and <Si+i = abstract(Si,S' i ), for i = 0,...,3. Therefore, 
the algorithm returns the following set of states: 

S = { (main Len xs, []), (lenmax xs, [(fst x,x)]), 

(fst (len xs , max xs), []), (len xs, []) } 

The total correctness of the algorithm in Fig.[7|is stated in the following theorem: 
Theorem 1 

Given a flat program 1Z and an initial term t, the algorithm in Fig. \7\ terminates 
computing a set of states S such that (t, []) is 5-closed. 
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6 Extraction of the Slice 

In this section, we introduce the final step of our slicing process, i.e., the extraction 
of the program slice. Let us recall that it must be a fragment of the original pro- 
gram — thus no instantiation of variables is allowed — and produce the same outputs 
for the slicing criterion as the original program. Here, we follow the simplified form 
for program slices, i.e., case branches of the form p — > T are deleted, and function 
definitions of the form f(x^) — T do not appear in the slice. 

First, we need the following auxiliary function that returns the terms which are 
relevant in order to extract a program slice from the set of states computed by the 
algorithm of Fig. 

Definition 11 {residual calls) 

Let S be a set of states returned by the algorithm of Fig. and let T$ = {t | 
(t, S) G S}. Then, the set of residual calls of S is defined as follows: 

residuaLcalls{S) = T s U {*' | (t, S) eS,t' 6 calls (S), and t' is not T 5 -closed} 

Observe that, in the above definition, residual _calls should also return the function 
calls in the computed stacks when they are not closed w.r.t. the set of first com- 
ponents of the states in S. This is mandatory in order to ensure a full equivalence 
w.r.t. the standard semantics. Program slices can now be built as follows: 

Definition 12 {construction of program slices) 

Let S be a set of states returned by the algorithm of Fig. Then, a program slice 
is obtained from build slice {residual .calls (S)), where function build slice is defined 
as follows: 

buildslice{{ }) = { } 

build slice {{f(Q} U T') = {/ (x£) = e' } U build slice { V ) 

where f(x£) = eeR, p = {x n >-> t n }, 
and [ejp — >* e' ■/-> 

The new calculus which is used to construct the rules of the slice is depicted in 
Fig. [HI First, note that the symbols "[" and "]" in an expression like \e\p are purely 
syntactical, i.e., they are only used to mark subexpressions where the inference rules 
may be applied. The substitution p is used to store the bindings for the program 
variables. Let us briefly explain the rules of the new calculus. 

Rule var simply returns a variable unchanged. Rule cons applies to constructor- 
rooted terms; it leaves the outermost constructor symbol and (recursively) inspects 
the arguments. 

Rules select and guess proceed similarly to their counterpart in Fig. but leave 
the case structure untouched; the substitution p is used to check the current value of 
the case argument. We only deal with variable case arguments since the considered 
expression is the right-hand side of some program rule (cf. Fig. [2J • Note that rule 
guess is now deterministic (and, thus, the entire calculus). 

Finally, rules fun and remove are used to reduce function calls: when there is some 
term in residual _calls{S) with the same outermost function symbol, we proceed as in 
rule cons; otherwise, we return T (which means that the evaluation of this function 
call is not needed). 
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var \x\p — > x 

cons [c(Q]p — ► c([ii]p,...,[4]p) 

select [(/)cose x o/ {p fc -> e fc }]p — ► (f)case x of { pj -» [e»]p'} 

guess [(/)case x o/ {p fc — > e fc }]p — > (f)case x of {p k -> [e^Jpfc} 

fun [f(£)]p /([falft-.W?) 

remove [f{t n )]p — ► T 

where in select: p(x) = c(t n ), pt = c(a^r), p' = {x n t— > fe} o p, and i £ {1, . . . , k} 

guess: p(a;) G A", p ; = {x p^} o p, and i g {1, . . . , k} 

fun: there is some term in residual _calls(S) rooted by / 

remove: otherwise 

Fig. 8. Simplified Unfolding Rules 
Example 12 

Consider the set of states computed in Example El From this set, function resid- 
uaLcalls returns the set of terms: 

{main Len xs, lenmax xs, fst (len xs , max xs), len xs} 

Now, we construct a residual rule for each term of the set. For instance, for the 
term "main Len xs" , the associated residual rule is: 

main op xs = fcase op of {Len — > fst (lenmax xs)} 

since the following derivation can be performed (with p = {op i— ► Len}): 

[fcase op of { Len — > fst (lenmax xs); Max — > snd (lenmax xs) }]p 
— ^select fcase op of { Len — > [fst (lenmax xs)]p } 
— >f un fcase op of { Len — > fst ([lenmax xs]p) } 
— >f un fcase op of { Len — > fst (lenmax [xs]p) } 
— > var fcase op of { Len — > fst (lenmax xs) } 

By constructing a residual rule associated to each of the remaining terms, the 
computed slice coincides with the (simplified version of the) program slice which is 
shown in Example [B] 

Now, we show that the result of Definition ^| is a program slice of the original 
program according to Definition [3] 

Theorem 2 

Let 1Z be a flat program and t a term. Let S be a set of states computed by the 
algorithm of Fig. from 1Z and t. Then, TV = build slice {residual .calls (S)) is a 
program slice of 1Z, i.e., 1Z' >z 1Z. 

Finally, the correctness of the computed slices (according to Def. is inherited by 
the correctness of the underlying partial evaluation process. 

Theorem 3 

Let 1Z be a flat program and t a term. Let S be a set of states computed by the 
algorithm of Fig.0from 1Z and t. If computations for t in 1Z do not suspend, then 
t computes the same values and answers in 1Z and in build _slice(residual -calls (S)). 
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Table 1. Partial evaluator vs program slicer — code structure 







main 


global 


local 


post 


util 


Total 


Partial evaluator 


(lines) 


306 


403 


888 


433 


316 


2346 




(functions) 


22 


43 


83 


44 


38 


230 


Program slicer 


(lines) 


232 


486 


249 


195 


419 


1581 




(functions) 


20 


50 


29 


26 


55 


180 



7 Implementation 

In order to check the practicality of the ideas presented so far, a prototype imple- 
mentation of the program slicer for Curry programs has been developed in Curry 
itself. The resulting tool covers not only the flat programs of Sect. [21 but also 
source Curry programs (which are automatically translated to the flat syntax). 
Moreover, it also accepts higher-order functions, overlapping left-hand sides, sev- 
eral predefined (built-in) functions, etc. The implemented tool is publicly available 
from http : //www . dsic . upv . es/users/elp/german/slicing/ 

It is worthwhile to note that the development of the program slicer required a 
small implementation effort since it was developed by extending an existing partial 
evaluator for Curry programs ((Albert et al. 2002|l . Table ^ shows the structure of 
both the partial evaluator and the program slicer, including the lines of code and 
the number of functions for each basic component: 

main : basic definitions and data type declarations, reading of source program, writ- 
ing of transformed program, etc; 
global : global control, including termination tests and generalization operations; 
local: local control, i.e., a non-standard meta-interpreter; 

post: post-processing transformation, i.e., renaming and post-unfolding compres- 
sion in the partial evaluator and extraction of the slice in the program slicer; 
util: general utilities and pretty printing. 

Basically, components main, local, and util were almost straightforwardly adapted 
from the partial evaluator to the program slicer. For instance, component local 
of the program slicer — which corresponds to the semantics shown in Fig. El — is a 
simplified version of the same component in the partial evaluator, since only a one- 
step unfolding is required here. More significant changes were made in component 
global. In contrast to the partial evaluator, the program slicer introduces the use 
of states and, thus, it required the implementation of rules replace and flatten, as 
well as the associated abstraction operator. Finally, component post of the partial 
evaluator was entirely replaced, since the program slicer does not perform neither 
renaming nor post-unfolding compression but should only extract the residual rules 
according to the calculus of Fig. |H1 

Our slicing tool is able to compute the slice of Example H3 thus it is strictly 
more powerful than naive approaches based on graphs of functional dependences. 
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In general, forward slicing has been proved particularly useful in the areas of pro- 
gram understanding, dead code removal, and code reuse. Now, we illustrate the 
application of the program sheer with some selected examples. First, we consider 
the program of Example |S] (in Curry syntax): 

main Len xs = fst (lenmax xs) 
main Max xs = snd (lenmax xs) 

lenmax xs = (len xs, max xs) 

len [] = Z 

len (x:xs) = Succ (len xs) 

max [x] = x 

max (x:y:ys) = if (x ^ y) then max (y:ys) 

else max (x:ys) 

Z ^ m = True 

(Succ n) ^ Z = False 

(Succ n) (Succ m) = n ^ m 

fst (a,b) = a 
snd (a,b) = b 

Given the slicing criterion "main Len xs" , our tool returns the following slice: 
main Len xs = fst (lenmax xs) 

lenmax xs = (len xs, T) 

len [] = Z 

len (x:xs) = Succ (len xs) 

fst (a,b) = a 

Here, the second rule of function main as well as the definitions of functions max, ^, 
and snd have been sliced away, since they are not needed when the first parameter 
of main is the constant Len. Note that the removal of case branches in the flat 
language is now viewed in Curry as the removal of rules in a function definition, 
e-g-, 

main op xs = f case op of { Len — > fst (lenmax xs) ; 

Max -> T } 

is simply written as follows: 

main Len xs = fst (lenmax xs) 
Let us now consider a similar situation but in a higher-order context: 

trans p xs = map (f p) xs 

map f [] = [] 

map f (x:xs) = f x : map f xs 
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f A = inc 
f B = dec 
f C = square 

inc x = Succ x 
dec (Succ x) = x 
square x = x * x 

Function trans applies a parametric function, f, to all the elements of a given list. 
Now, the computed slice w.r.t. the slicing criterion "trans A xs" is as follows: 

trans p xs = map (f p) xs 

map f [] = [] 

map f (x:xs) = f x : map f xs 

f A = inc 

inc x = Succ x 

Again, all functions but inc and the first rule for f have been deleted, which shows 
that our approach works well in the presence of higher-order functions. Finally, 
let us show an example which illustrates the removal of dead code due to lazy 
evaluation. Consider the following program: 

lenlnc n xs = len (incL n xs) 

len [] = Z 

len (x:xs) = Succ (len xs) 

incL n [] = [] 

incL n (x:xs) = inc n : incL n xs 

inc x = Succ x 

Here, function lenlnc takes a number and a list, and returns the length of the 
list which results from adding the given number to each element of the original 
list. Clearly, in a lazy context, function inc will never be executed. Therefore, the 
computed slice w.r.t. "lenlnc n xs" (i.e., no input data is known) is as follows: 

lenlnc n xs = len (incL n xs) 

len [] = Z 

len (x:xs) = Succ (len xs) 



incL n [] = [] 

incL n (x:xs) = T : incL n xs 
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Table 2. Partial evaluator vs program slicer — selected benchmarks 





PE 


Slicing 




Runtim 


g 




Size 






time 


time 


Oris 


Spec 


Sliced 


Orie 


Spec 


Sliced 


Benchmark 


ms 


ms 


ms 


/o 


/o 


bytes 


/o 


/o 


ackermann 


20490 


1370 


1330 


98.50% 


99.25% 


2039 


228.3% 


49.93% 


all ones 


ouyu 


i oon 




111.4U/0 


lUU.oo/o 


oOUz 


lOD. ZD /o 


00.4Z /o 


f ibonacci 


150 


270 


380 


81.58% 


102.63% 


2438 


64.93 


50.82% 


f iltermap 


280 


450 


1460 


84.93% 


100.00% 


2147 


28.50% 


69.26% 


f liptree 


2800 


1230 


1430 


92.31% 


93.71% 


2619 


202.33% 


52.20% 


f oldr .map 


80 


320 


630 


60.32% 


100.00% 


1784 


21.41% 


64.63% 


f oldr . sq 


70 


310 


670 


65.67% 


101.49% 


1763 


21.10% 


64.61% 


f oldr . sum 


6730 


1400 


1570 


80.25% 


98.09% 


4678 


35.85% 


13.92% 


f uninter 


504930 


2220 








5288 


657.19% 


61.86% 


gauss 


11680 


950 


700 


82.86% 


98.57% 


2115 


61.56% 


42.36% 


iterate 


1950 


750 


890 


25.84% 


103.37% 


1968 


117.99% 


69.61% 


kmpAAB 


710 


990 


380 


31.58% 


105.26% 


3348 


42.29% 


75.30% 


kmpAAAAAAB 


9870 


3250 


790 


35.44% 


100.00% 


3968 


104.86% 


69.78% 


power 


12710 


890 


620 


95.16% 


103.23% 


2830 


203.29% 


46.93% 


quicksort 


450 


670 


260 


165.38% 


103.85% 


2711 


84.06% 


81.48% 


reverse 


4590 


970 


680 


98.53% 


101.47% 


1873 


251.09% 


53.87% 


Average 


36411 


1127 


862 


80.65% 


100.79% 


2817 


143.13% 


58.12% 



The occurrence of T in the definition of incL shows that the values of the elements 
in the list are not needed to compute the length of the given list. 

Let us mention that, in contrast to the original partial evaluator, the implemented 
program slicer can deal with larger programs efficiently. This is mainly due to the 
monovariant/monogenetic nature of the underlying partial evaluator, which simpli- 
fies the computation of a closed set of terms. Table|2]shows a summary of the exper- 
iments conducted on an extensive set of benchmarks. We used the Curry— ^Prolog 
compiler of PAKCS 1.6.0 HHanus et al. 2004jl running on a 2.4 GHz Linux-PC (Intel 
Pentium IV with 512 KB cache). Runtime input goals were chosen to give a rea- 
sonably long overall time. Code size was obtained by measuring the intermediate 
FlatCurry files (suffix .fey) generated by PAKCS. The considered benchmarks are 
available from http://www.dsic.upv.es/users/elp/germaii/slicing/ 

The results in Tabled show that the program slicer is in almost all cases much 
faster than the partial evaluation tool. As expected, the runtime of the sliced pro- 
grams do not significantly differ from the runtimes of the original ones, since only 
some program rules (or expressions) have been deleted; this shows that little over- 
head has to be paid for adding extra functions to a program. Anyway, the main 
purpose of slicing is not speedup, but reducing code size. In this case, slicing has 
managed an overall code size reduction of 57.60% whereas the partial evaluator has 
increased the code size by 162.26%. Indeed, the slicing never increases the code 
size, while the partial evaluator has increased the code size by 657.18% in the worst 
case. On the other hand, there are cases where specialization achieves much smaller 
code size than slicing, e.g., for f iltermap where the specializer has managed to 
transform the composition of several higher-order functions into a single first-order 
function. 
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8 Related Work 

Although program slicing was originally introduced in the imperative programming 
setting, it has been applied to almost all programming paradigms, e.g., object- 
oriented programs ( |Tip et al. 1996| ILarsen and Harrold 19961 ISteindl 1 9981. logic 
programs (Sc hoenig and Ducasse 199"6|lZhao et al. 200l)l . functional programs (Biswa s*1997l 
|Field and Tip 1 998*1 ), or algebraic specifications l|Woodward and Allen 1998|l . Al- 
though we are not aware of any previous work addressing forward slicing of multi- 
paradigm functional logic programs, in the following we review the closest ap- 
proaches to our work. 

Within imperative programming, the closest approach is that of Blazy and Facon 
( 1998), who use partial evaluation for program understanding in Fortran. Since they 
do not want to change the original structure of the code, no unfolding is performed 
(similarly to our one-step unfoldings). Also, they neither introduce new variables 
nor rename the existing ones. In this work, we have followed a very similar approach 
in order to define a forward slicing algorithm for functional logic programs. In both 
approaches, a simplified partial evaluator that does not change the structure of the 
original program has been introduced. 

Within the logic programming paradigm, Gyimothy and Paakki ( 1995) introduce 
the first approach to slicing. They define a specific slicing algorithm which com- 
putes a slice of the proof tree in order to reduce the number of questions asked by 
an algorithmic debugger ( |Shapiro 1983| ). The slice is computed from a static depen- 
dency graph containing only oriented data dependencies. In contrast to our work, 
their algorithm cannot be not used to compute executable programs. Schoening and 
Ducasse (|1996i) define the first (backward) slicing algorithm for Prolog programs 
which produce executable slices. They introduce an abstraction relation in order to 
formalize the notion of program slice. Our notion of slice in Sectionals somehow in- 
spired by this work. Leuschel and S0rensen l|1996p introduce the concept of correct 
erasure in order to detect and remove redundant arguments from logic programs. 
They present a constructive algorithm for computing correct erasures which can be 
used to perform a simple form of slicing. Actually, Leuschel and Vidal (2005) have 
very recently introduced a new approach to forward slicing of logic programs which 
is based on a combination of the ideas presented in this work and the redundant 
argument filtering of Leuschel and S0rensen (1996). 

As for functional programs, Field and Tip (.1998:) present a very detailed study 
of the concept of slicing associated with left-linear term rewriting systems (a no- 
tion of "program" very close to the one considered in our work). Their definition 
of slice is also based on a notion of neededness but, in contrast to our work, they 
consider backward slicing (and compute slices that are not executable on the stan- 
dard interpreter). Another closely related approach has been introduced by Reps 
and Turnidge (1996). They define a backward slicing technique for functional pro- 
grams which can be used to perform a sort of program specialization that cannot be 
achieved by standard partial evaluation. Their work can be seen as complementary 
to ours, since we are interested in the use of partial evaluation to perform program 
slicing. On the other hand, Hallgren ||2jQj[)2J) reports some experiments with a Haskell 
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slicer. It is mainly based on the construction of a graph of functional dependences 
and, thus, it is less powerful than our partial evaluation-based slicer. 

Very recently, Ochoa et al. ( 2004) have introduced a novel approach to dynamic 
backward slicing of functional logic programs which is based on an extension of 
the tracing technique of BraBel et al. (2004). In particular, their approach relies on 
constructing a redex trail of a given computation in order to compute all program 
dependences. Basically, a redex trail is a directed graph which records copies of all 
values and redexes of a computation, with a backward link from each reduct to 
the parent redex that created it. Then, a backward slice can easily be obtained by 
mapping the relevant nodes of the redex trail to concrete locations of the source 
program. This approach has also been applied to Haskell programs by Chitil ( 2004 ). 
These approaches are not based on partial evaluation but on well-known techniques 
for debugging functional programs. Therefore, the implementation of a dynamic 
slicer is relatively easy if one already has a debugger based on redex trails. However, 
they are not useful in order to develop a static slicing tool. In contrast, our approach 
can be used to perform both static and (forward) dynamic slicing. 



9 Conclusions and Future Work 

This work introduced the first approach to forward slicing of multi-paradigm (func- 
tional logic) programs. Although some extensions were needed, our developments 
basically rely on adapting and extending an online partial evaluation scheme for 
such programs. Thus, the implementation of an associated slicing tool was easily 
achieved by extending an existing partial evaluation tool. Moreover, our approach 
helps to clarify the relation between program slicing and partial evaluation in a func- 
tional logic context. The application of our developments to (first-order) lazy func- 
tional programs would be straightforward, since the considered language is a con- 
servative extension of a pure lazy functional language and the (online) partial evalu- 
ation techniques are similar, e.g., positive supercompilation (S0rcns en et al. 1996). 
On the other hand, similar ideas have already been applied to define a forward 
slicing technique for logic programs IjLeuschel and Vidal 2 005 ) . 

An interesting topic for future work is the extension of our approach to perform 
backward slicing. Here, the computed slice should contain those program statements 
which are needed to compute some selected fragment of the output. While forward 
slicing is useful for program understanding, reuse, maintenance, etc., backward 
slicing can be applied to, e.g., program debugging, specialization and merging. 
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Appendix A Proofs of technical results 

Lemma Q] 

Let s be a flattened state. Then s has the form (v, [ ]), where v is a value, or 
{f(Jn)) S)i where f(t n ) is an operation-rooted term. 

Proof 

We prove the claim by contradiction. Let s be a flattened state of the form (v, S) 
where v is a value and S is not empty. Then rule replace could be applied to s, thus 
contradicting the hypothesis of the lemma. Thus, s should be of the form (v, []) or 
(e, S), where e is not a value. To show that e must be an operation-rooted term, it 
suffices to consider that rules replace and flatten do not return case expressions (only 
operation-rooted terms) and that the initial state cannot contain case expressions 
(since it was returned by the operator unfold). □ 

Lemma 

Let S be a set of flattened states and S' a set of unfolded states (as returned by 
unfold). Then the states in S U S' are closed w.r.t. abstract(S,S'). 

In order to prove this lemma, we first need the following preparatory definitions 
and results. We use the notation depth(t) to denote the maximum number of nested 
symbols in the term t. Formally, if t is a constant or a variable, then depth(t) = 1. 
Otherwise, depth(f (t n )) = l + max({depth(ti), . . . , depth(t n )}) . The following result 
establishes the transitivity of the closedness relation on terms. 

Proposition 1 {Alpuente et al. 1998) 

If term t is Ti-closed, and the terms in T\ are T2-closed, then t is T2-closed. 

We define the complexity Air of a set of terms T as the finite multiset of nat- 
ural numbers corresponding to the depth of the elements of T. Formally, M T = 
{depth(t) | t € T}. We consider the well-founded total ordering < mu ; over multiset 
complexities by extending the well-founded ordering < on IN to the set M(M) 
of finite multisets over IN. The set M(M) is well-founded under the ordering 
< m ui since IN is well-founded under <. Let M., M! be multiset complexities, then: 
M< m uiM' & 3X C M,X' C M' such that M = {M 1 - X') U X and 
Vn G X, 3n' £ X' such that n < n' . This ordering is naturally extended to 
sets of states by simply considering the terms represented by the states in each set. 

Now, we can proceed with proof of Lemma We follow the scheme of the proof 
of Lemma 5.13 in ( |Alpuente et al. 199 8) but extend it to deal with states: 

Proof 

We proceed by structural induction on S U S' . Since the base case is trivial (S is 
always 5-closed), we consider the inductive case. Let S" — {s[, . . . , s' n }, n > 1, 
be the set of states resulting from flattening the states in S' , i.e., S" — {s 2 ' | Sj 6 
S' and s 2 =^* ep | ace /f| att en 4 ^replace/flatten}- Trivially, we have that Ms> = M s >> 
and that S U S' is closed w.r.t. S U S" , since the process of flattening does not 
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change the terms represented by the states. By the definition of abstract, we have 
the following equalities: 

abstract(S,S') = abstract(S,S") 

— abs(abs(. . . abs(S, s() . . . , s' n ) 

— abs(abstract(S, S" \ {s' n }), s' n ) 
= abs(S*,s' n ) 

where S* = abstract(S,S" \ {s' n }) and s' n is an arbitrary state of S" . By the 
inductive hypothesis, we know that S U (iS" \ {s' n }) is closed w.r.t. S*. Now, we 
proceed with the call abs(S* , s' n ). Here, we distinguish the following cases depending 
on the structure of s' n : 

s' n = (x, []): Then abs(S*, s' n ) — S* and the claim follows by Lemma ^ 
s' n = (c(t n ),[])\ Assume that t' m are the maximal operation-rooted subterms of 
c(Q. Then abs(S*,s' n ) = abstract{S* ,S C ), with S c = {{t' ml [])}. Since M s -us- 
<mui -Ms*u{s' }i the proof follows by Lemma^^d the inductive hypothesis. 
s' n = (f(t n ),S): Then, following the definition of function abs, we consider three 
possibilities: 

• If there is no state in S* whose first component is rooted by /, then 
abs(S* , s' n ) = S* U {s' n }. Thus, the claim follows by LemmaQ] 

• If the state is ignored (because it is already closed and it is not equal to any 
existing state), then abs(S* , s' n ) — S* . Again, the claim follows trivially by 
Lemma ^ 

• Otherwise, there exists some state {f{t' n ), S 1 ) and 

abs(S*,s' n ) = abstracts* \ {</©, S')}) U {(/®, S')}, &) 

where m»ff({/®,S'),{/(U5}) = ((/®)_ 1 _^>.<5 / ).^ / = caKs(<n)U 
calls') U calls{S), msg{f{t' n )J(t n )) = f(t»), trxUiO) = /(&)> and 
IJ 2{f {!■")) = f(tn)- Now, by definition of function msg, it is easy to check 
that S* U {<} is closed w.r.t. (S* \ {(/©, S'}}) U {(/©, 5')} U 5^ and 
that A4 (5 » ^ {(/(t4),5')})u{(/(tf),s')}u<s/ <rn.ni M s , u{K} . Therefore, the proof 
follows by Lemma ^and the inductive hypothesis. 

□ 

Theorem^ 

Given a flat program 1Z and an initial term t, the algorithm in Fig. terminates 
computing a set of states S such that (t, []) is 5-closed. 

Proof 

The 5-closedness of (<,[]} is a direct consequence of Lemma [21 and Proposition ^ 
Lemma El ensures that the arguments of the operator abstract are always closed 
w.r.t. the new set of states, while Proposition guarantees that the closedness of 
the initial state is correctly propagated through the whole process. 

The termination of the algorithm can be derived from the following facts: 
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1. Each iteration of the algorithm is finite. The finitcness of the application of the 
unfolding operator is obvious (since only one function unfolding is allowed). The 
termination of one application of operator abstract can easily be proved by follow- 
ing the scheme of the proof of Lemma [21 the computation terminates since each 
recursive call to abstract uses a set of states which is strictly lesser than the previous 
call (w.r.t. < mu i). 

2. The termination of the whole iterative process is a consequence of the following 
facts: 

• The number of states in the current set Si cannot be greater than the number 
of different functions in the original program, since the abstraction operator 
ensures that there is only one state for each function symbol of the program. 
Thus, it cannot grow infinitely. 

• The number of states in the set <Si+i is always equal to or greater than the 
number of states in the set 5^. This property is immediate, since we only 
remove states in the last case of the definition of abstract and, there, we 
replace one state by a new (generalized) state. 

• Finally, each time one state is replaced by a new one, the new state is equal 
to or smaller than the previous state (according to the ordering based on 
the depth of the terms). If the new state has the same depth than the old 
one, then the process would terminate, since they would be equal (modulo 
renaming). If it is strictly smaller, then it will eventually reach an state whose 
first component is of the form / (xJT) and, hence, it cannot be generalized again. 

□ 

Theorem^ 

Let TZ be a flat program and t a term. Let S be a set of states computed by the 
algorithm of Fig. from TZ and t. Then, TZ' = build slice {residual .calls (S)) is a 
program slice of TZ, i.e., TZ' > TZ. 

Proof 

This result is an easy consequence of Def. I12land the calculus in Fig. [S] 

• If there is a rule /(a^T) = e G 1Z and there is no term f(t n ) G residual _calls (S) , then 
1Z' does not contain a definition for /, i.e., f{~x^) = T G 1Z' and, trivially, T > e. 

• Otherwise, f(x^) = e G TZ and f(x^) = e' G TZ' with \e\p — >* e' -f-^ and 
p = {x n i— » t n }. Now, we prove that e' >; e by induction on the length I of the 
derivation [e]p — >* e'\ 

Base case (I = 1). In this case, we only have the following possibilities: 

— e is a variable; thus, e' = e and the claim follows trivially. 

— e = c() is a constructor constant; then, e' — e and the claim follows. 

— e = g{t' m ) is operation-rooted and there is no term in residual _calls{S) rooted 
by g. Then, e' = T and e' >^ e. 

Induction case (I > 1). Here, we distinguish the following cases: 
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— e = c(t[, . . . , t' m ) with c € C and m > 0. Then, e' = c(p{]p, . . . , and 
the claim follows by induction. 

— e = {f)case x of {p x — > e x ; . . . ;pk — > e fc } with p(a:) = c(C) and p 2 = c(y^). 
Then, e' = (f)case x of {p x -> T; . . . ; pj -> [e l ] / 9 / ; . . . ; p k -> T} with p' = 
{j/m l—> CI ° P- By the inductive hypothesis, we have [ejp' >z e% and, thus, 



— e = (f)case x of {pi — » ei;...;pfc — > e/j} with p(a;) G A". Then, e' = 
(/)case z 0/ {pi -> [ei]pi; . . . ;p fc -> [e fc ]p fc }, with = {x ^ pj o p, 
i G {1, . . . , k}. By the inductive hypothesis, we have [e,]pt y e% for all i = 
1, . . . , k. Therefore, e' >r e. 



— e = . . . , 4) with g E J- . Then, either e' = g([t[]p, [CI/ 3 ) and the 



claim follows by induction, or there is no term in residual _calls(S) rooted by 
g and e' = T >z e. 

□ 

Theorem 

Let 1Z be a flat program and £ a term. Let S be a set of states computed by the 
algorithm of Fig.0from 1Z and t. If computations for t in 1Z do not suspend, then 
t computes the same values and answers in 1Z and in build _slice{residual-calls{S)). 

Proof 

We present an sketch of the proof; the complete formalization is not difficult 
but would require the introduction of many notions and results from the origi- 
nal narrowing-driven specialization framework. Basically, the proof proceeds in a 
stepwise manner as follows: 

• First, we consider the construction of a specialized program from the states in S 
following the standard approach to narrowing-driven partial evaluation. Formally, 
we construct a residual program TZ' by producing a residual rule of the form 



resulting residual program fulfills the syntax of flat programs (in spite of the form 
of S[t]). Basically, ren(S[t]) returns a term f(x^) where / is a fresh function symbol 
and %l are the different variables of S[t]. By the correctness of narrowing-driven 
partial evaluation (since t is 5-closed by Theorem QJ, we know that all the com- 
putations for (t, [ ]) in the original program can also be done for (ren(t), [ ]) in the 
residual program constructed so far. 
• Then we consider a new program TZ" which is obtained from TZ' as follows: each rule 
in TZ' of the form ren(S[t]) — ren(S[t']) is replaced by a new rule ren{t) = ren(t'). 
This replacement is safe in our context since the one-step unfolding does not affect 
to the current stack. A precise equivalence between the computations in TZ' and 
TZ" can easily be established under the extended operational semantics of Fig. El 
Note that renaming is still necessary to ensure that residual rules fulfill the syntax 




of Fig. 
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• Now, we define a new program TZ'" which is obtained from TZ" as follows: each 
rule ren{t) = ren(t'), with t = /(<„), is replaced by a new rule f(x^) — e', where 
f(xn) = e is a rule of the original program TZ, are fresh variables, [e]p — >* 
e' -f- — >, and p = {x n <— > t n }. There is no need to apply a renaming of expressions in 
this case, since the program so constructed already fulfills the syntax of Fig. (cf. 
Theorem|5J|. Now, each derivation for (ren(t), []) in TZ" can also be done for (t, []) 
in TZ'" using the extended operational semantics of Fig. H3 This is justified by the 
fact that the only difference between the rules of TZ" and TZ'" is that bindings are 
applied to program expressions in TZ" while they are represented implicitly in TZ'" 
by means of case expressions in the right-hand sides of the program rules. 

• Finally, we extend TZ'" by adding a residual rule of the form f(x^) = e' for 
each call f(t n ) G {f | (t, S) £ S,t' 6 calls(S), and t' is not T^-closed}, where 
Tg = {t (t,S) G 5}, f(x7 t ) = e is a rule of the original program TZ, are 
fresh variables, [e]p — >* e' and p — {x n i— > i„}. The extended program coin- 
cides with the result of build slice (residual _calls (S)) . The claim follows by checking 
that each derivation for (t, [ ]) in TZ'" using the extended semantics can also be 
performed for t in build _slice(T) using the standard operational semantics. In- 
tuitively, this equivalence holds because the only difference — we ignore here the 
suspension of flexible case expressions since we only consider computations which 
do not suspend — between the standard and the extended operational semantics is 
that the unfolding of some outer function call is (possibly) delayed until a complete 
one-step evaluation is possible. Therefore, the same computations can be proved 
with both calculi, except when there is some inner call which never reduces to a 
value (due to an infinite derivation). However, we ensure the equivalence even in 
this case by adding residual rules for the calls in the stack components which are not 
Tg-closed, i.e., for those calls which have some inner call with a non-terminating 
derivation. 



□ 



